[Previous] [Next] [Index] [Thread]

Java security problems (fwd from Risks Digest #17.77)

-------------------------- Forwarded message --------------------------
Date: Sun, 18 Feb 1996 23:57:02 -0500
From: Drew Dean <ddean@CS.Princeton.EDU>
Subject: Java security problems
 
We have discovered a serious security problem with Netscape Navigator's 2.0
Java implementation.  (The problem is also present in the 1.0 release of the
Java Development Kit from Sun.)  An applet is normally allowed to connect
only to the host from which it was loaded.  However, this restriction is not
properly enforced.  A malicious applet can open a connection to an arbitrary
host on the Internet.  At this point, bugs in any TCP/IP-based network
service can be exploited.  We have implemented (as a proof of concept) an
exploitation of an old sendmail bug.
 
If the user viewing the applet is behind a firewall, this attack can
be used against any other machine behind the same firewall.  The
firewall will fail to defend against attacks on internal networks,
because the attack originates behind the firewall.
 
The immediate fix for this problem is to disable Java from Netscape's
"Security Preferences" dialog.  An HTTP proxy server could also
disable Java applets by refusing to fetch Java ".class" files.  We've
sent a more detailed description of this bug to CERT, Sun, and
Netscape.
 
A second, also serious, bug exists in javap, the bytecode
disassembler.  An overly long method name can overflow a stack
allocated buffer, potentially causing arbitrary native code to be
executed.  The problem is an unchecked sprintf() call, just like the
syslog(3) problem last year.  Many such bugs were in the alpha 3
release's runtime, but were carefully fixed in the beta release.  The
disassembler bug apparently slipped through.  This attack only works
on users who disassemble applets.  The fix is to not run javap until
Sun releases a patch.
 
Note that we've only had success in exploiting the first flaw on an SGI.
Windows 95 and DEC Alpha versions of Netscape have other bugs in their
socket implementations that make it harder (although not necessarily
impossible) to exploit the problem.  This is the second time that unrelated
implementation bugs have prevented us from demonstrating security problems
in Java.
 
http://www.cs.princeton.edu/~ddean/java will contain more information
soon, including a revised version of our paper, to appear in the 1996
IEEE Symposium on Security and Privacy.
 
Drew Dean       <ddean@cs.princeton.edu>
Ed Felten       <felten@cs.princeton.edu>
Dan Wallach     <dwallach@cs.princeton.edu>
  Department of Computer Science, Princeton University
 
For more information, please contact Ed Felten, 609-258-5906, FAX 609-258-1771.
------------------------ End forwarded message ------------------------

Comments from the www-security crew?

Are these problems serious enough that an unfirewalled site must forbid
the use of the Netscape 2.0 implementation of Java?  Or should it be
sufficient to alert Netscape users about the problem and ask them to
watch for suspicious behavior on the part of Java applets?

In particular, will Java alert users about IP connections it makes?
I'm concerned about applets that might make HTTP retrievals from local
web servers that normally restrict access to our campus, then upload
the retrieved material back to the server from which the applet
originated.  I might be willing to live with this risk if users will
see a message saying something like, "Java applet retrieving document
http://foo.rice.edu/forbidden/blah.htm".

-- Prentiss Riddle ("aprendiz de todo, maestro de nada") riddle@rice.edu
-- RiceInfo Administrator, Rice University / http://is.rice.edu/~riddle
Follow-Ups: